FYI: @julienrbrt feel free to share your thoughts on the adr

Want to echo what Julien said. It seems there is a change in design that is not being articulated here.

Can we get an understanding of what you have in mind for rosetta? Is it standalone or does it continue to be imported into chains. There is mention of plug-in based system, what are the trade offs to doing reflection based. Currently Rosetta is being imported into the sdk so it's not entirely standalone as it's imported into the sdk and apps. We separated it into a separate go.mod for maintenance reasons but didn't put it in a separate repo so it's kept up to date with the latest sdk changes.

Hi @julienrbrt ! Thx for the observations!

1. we would need to create a repo inside cosmos, like "rosetta" or something similar
   2 .By binary I asume you mean from simapp? I see that every chain is adding rosetta into thier nodes binary by using the exported function rosettaCmd.RosettaCommand(interfaceRegistry, appCodec) so that wouldn't change except for the import path directory.
2. I'm not sure I'm following the relationship between the plugins and the vanity url, so if you could elaborate more I could provide a better response

Hi @julienrbrt ! Thx for the observations!

1. we would need to create a repo inside cosmos, like "rosetta" or something similar
   2 .By binary I asume you mean from simapp? I see that every chain is adding rosetta into thier nodes binary by using the exported function rosettaCmd.RosettaCommand(interfaceRegistry, appCodec) so that wouldn't change except for the import path directory.
2. I'm not sure I'm following the relationship between the plugins and the vanity url, so if you could elaborate more I could provide a better response

1. 👍🏾
2. Right, this makes sense, but as rosetta will support only released versions, this means we will need to remove it from simapp here, as it will be incompatible with our development version. Are you going to do some early integration as well?
3. I had no questions about the plugins, and indeed this is unrelated to the vanity url. I am simply curious is you are going to break the go mod or keep it the same and update figure out vanity url config.

Hi @tac0turtle we appreciate you jumping into the discussion!

It seems there is a change in design that is not being articulated here.

What do you think is unclear or not being correctly articulated? glad to expand over your concerns

Is it standalone or does it continue to be imported into chains.

Rosetta will always run as a service independently of the app/node, It can be imported into chains binaries with the rosettaCmd.RosettaCommand(interfaceRegistry, appCodec) o separately, the only difference would eradicate on how you start that server. We believe that running Rosetta standalone removes the need to have the chain node binary and follows the objective of decoupling things.

what are the trade offs to doing reflection based.

Well we made an ADR for plugins as julien mentioned. Using reflection is desirable but due to chains running on older versions of cosmos. we believe it will take a lot of time until chains perform the upgrade, implement the optional service for reflection and adopt rosetta. Not even cosmos-hub chain node is running neither on 0.46 nor on 0.47. We prioritized usability and adoption, since the reflection solution is already implemented on hudl tool and the proposed plugin solution is straight forward / simple, we believe implementing reflection shouldn't be a big issue

Currently Rosetta is being imported into the sdk so it's not entirely standalone as it's imported into the sdk and apps.

Right, Rosetta is imported and loaded through the function mentioned before and nothing more (kudos tho whoever came with such decoupled approach), same as for other cosmos chains, so switching repos shouldn't represent a risk of breaking stuff.

The main reason (as I understand it) for rosetta being inside a node app is so it could have access to the app interface registries and codecs, but we solved that issue with the plugins things, so we don't really see a reason why the app should have rosetta inside if it can perfectly run well outside of it.

@julienrbrt
2. Right, I honestly don't see the point of having rosetta inside a binary (except for the registered inferfaces we talked about a few weeks ago, thing that we intend to solve with the plugins update) at the end of the day, puting it inside the binary is just adding an extra command to trigger it without really impacting on its functionability or configurations.
3. I don't really have a strong opinion here to be honest. I'm inclined to configuring the vanity since I feel thats the cleanest approach, we will follow whatever is the desired practice for these cases.

Well we made an ADR for plugins as julien mentioned. Using reflection is desirable but due to chains running on older versions of cosmos. we believe it will take a lot of time until chains perform the upgrade, implement the optional service for reflection and adopt rosetta. Not even cosmos-hub chain node is running neither on 0.46 nor on 0.47. We prioritized usability and adoption, since the reflection solution is already implemented on hudl tool and the proposed plugin solution is straight forward / simple, we believe implementing reflection shouldn't be a big issue

this doesnt really make sense to me, why does a chain need to be on 0.46 or 0.47 to use reflection? Grpc Reflection is native to grpc and is live on all chains already. Im not the biggest fan of the plugin design as it doesnt scale.

Which plugins will be supported in the repo?

We can move it to a new repo but rosetta is a low priority for us in terms of other things that need to be done. Also with moving it to a new repo i guess you are agreeing to keep it up to date at all times when releases come out right?

@julienrbrt

Rosetta connects to a cosmos node, even when the node "depends" on rosetta because it is part of the CLI, Rosetta actually consumes the node, not the other way around, we have seen that in some cases the Rosetta sub repo suffers from breaking changes on non released things due to refactors or mass implementation, we would like to avoid that

@tac0turtle

this doesnt really make sense to me, why does a chain need to be on 0.46 or 0.47 to use reflection? Grpc Reflection is native to grpc and is live on all chains already. Im not the biggest fan of the plugin design as it doesnt scale.

Well, you are right about reflection and scaling. what I meant is that hubl does the job of getting the interfaces and their respective implementation through reflection but it is not compatible with old versioning, I didn't want to repeat the efforts, but now I'm exploring on reflection to achieve it.

Which plugins will be supported in the repo?

We are working on onbiarding Cosmos-hub, Osmosis and Evmos to test different ecosystems, after that we would provide guidelines for interested zones on how to make their own plugins.

We can move it to a new repo but rosetta is a low priority for us in terms of other things that need to be done. Also with moving it to a new repo i guess you are agreeing to keep it up to date at all times when releases come out right?

The main objective behind the new repo is to keep it well maintained.

Well, you are right about reflection and scaling. what I meant is that hubl does the job of getting the interfaces and their respective implementation through reflection but it is not compatible with old versioning, I didn't want to repeat the efforts, but now I'm exploring on reflection to achieve it.

maybe for all future versions we do reflection, So anything that uses .47+ gets reflection everything before doesnt get anything. We shouldn't spend much time fixing the current state if the next state will be much better.

We are working on onbiarding Cosmos-hub, Osmosis and Evmos to test different ecosystems,

these wont be merged into the repo right? Ideally zondax time is not spent on adding plugins and other things that are needed for users. Rosetta isnt used by many.

if the plan is to build rosetta as a stand alone thing that apps dont import then this is good, but its still unclear to me which direction this is being taken. Id prefer this is something that apps dont need to import and can just start and it works

talked to @jleni. We can spin it out, the gotcha is we have to change the documenetation to mention rosetta as a proxy and there isnt a need to import it into the rootcmd anymore,

Ill close this ADR as its not needed, mainly needed a quick discussion